Method and system for securely scanning network traffic

ABSTRACT

Secure network communications via a firewall device are provided between a first device and a second device, where an encryption parameter is shared by the devices. A data packet sent by the first device may then be copied within the firewall device, so that the copy of the data packet can be decrypted within a portion of the firewall device. In particular, the portion of the firewall device in which decryption takes place is defined such that contents of the portion are inaccessible to an operator of the firewall device. Thus, scanning of the decrypted copy of the data packet for compliance with a predetermined criterion may take place within the firewall device, without an operator of the firewall device having access to the contents of the data packet to be transmitted. Thereafter, the original data packet can be forwarded to its originally intended recipient.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to the formation and use of secure networkconnections. More specifically, the present invention relates to safelyscanning network connections without sacrificing user privacy.

2. Description of the Related Art

Computer networks, and in particular Wide Area Networks (WANs) such asthe Internet, provide opportunities for the misuse and abuse ofcommunications traveling thereover. For example, two users communicatingvia the WAN may have their communications intercepted and/or altered.Also, it is possible for one user to misrepresent his or her identity toanother user. As a final example, a user may utilize network resourcesand communications to disrupt all or part of the network.

Thus, there is a need for both privacy and authentication between usersof the WAN communicating with one another. In other words, users shouldbe able to rely on the fact that their transmissions will not beintercepted or altered, and that transmissions from someone purportingto be a particular user do in fact originate from that user.

One type of defense against ill-intentioned uses of the WAN is a deviceoperating at the edge of a private network, such as a Gateway, Firewallor some other dedicated network appliance. Such a device operates tofilter transmissions between the private network and the WAN and/or toprotect the transmissions that do go through by encrypting/decrypting(i.e., encoding/decoding) those transmissions.

Other related types of defenses function by establishing the identity ofa sender and/or recipient before sending/receiving a communication.Still other defenses include establishing a secure channel between twocommunicating devices.

A particular conventional protocol for providing security betweendevices operating over an Internet Protocol (IP) network is known asIPsec. Short for IP Security, IPsec is a set of protocols supporting thesecure exchange of IP packets at a network layer. Two of the protocolsused are the Authentication Header protocol (AH) and the EncapsulatingSecurity Payload protocol (ESP).

AH is designed to ensure that transmitted packets are not altered duringtransit over the network, but does not protect the contents of thepackets from being viewed by other users of the network such asintercepting parties. ESP, on the other hand, ensures theconfidentiality of the packet contents. ESP provides an optionalauthentication mechanism; however, this mechanism is only forauthenticating the data payload of the packet (and associated ESPheaders/trailers). Therefore, ESP does not authenticate an IP Header ofa packet indicating an original IP address on the network from which thepacket originated. It is also possible to use AH and ESP in conjunctionwith one another, in order to achieve the advantages of both.

Whether using AH or ESP, IPsec operates in either transport or tunnelmode. Transport mode is often used in host-to-host communications; i.e.,when the peer devices are the endpoints of communication. Transport modeis most useful within an overall IPsec environment including the twoendpoints. Tunnel mode is typically used in communications between anIPsec-protected system and some other endpoint, such as communicationssent from a private network over the Internet. In tunnel mode, thepayload of a secured IP packet carries another packet containing theactual data payload to be transmitted.

A common use of the tunnel mode is to implement a Virtual PrivateNetwork (VPN). VPNs are networks that use publicly-available networkresources, such as the Internet, to construct a network accessible onlyby selected parties. For example, a company may create its own versionof a Local Area Network (LAN) using the Internet, or a worker workingfrom a remote location may be able to utilize company resources at acompany headquarters.

In order to implement the various protocols and modes of IPsec such asthose discussed above, a security association (SA) is typically formed.An IPsec SA is essentially a contract or agreement between partiesdefining conditions according to which the two parties will communicate.For example, an IPsec SA is typically a one-way connection that defines,for example, encryption algorithms to be used during informationexchange. SAs are defined by such parameters as an IP destinationaddress and a security protocol identifier (e.g., AH or ESP). SAstypically include a security parameter index (SPI), which is a 32 bitidentification number.

If an IPsec SA is considered a contract or agreement, then the termsthereof can be considered to be negotiated by a separate protocol (ormanually). In other words, both communicating parties must agree onactions that will be taken on communicated packets in order toencrypt/decrypt those packets. One such protocol is known as theInternet Security Association and Key Management Protocol (ISAKMP), andone implementation of ISAKMP is known as the Internet Key Exchange(IKE).

IKE typically operates in two phases. In a first phase, parties agree asto how to protect further negotiation traffic. For example, IKE mayauthenticate a sender by virtue of, for example, public key encryption,also known as Diffie-Hellman encryption. In public key encryption, eachuser generates a public and private key, where the public key is thensent to the other party. When each user combines his own private keywith the other's public key (and perhaps additional information), theyeach obtain an identical secret key. This secret key serves as a basisfor deriving subsequent cryptographic keys.

In this way, a first user can encrypt a message using the second user'spublic key, and then only the second user (using his own private key)will be able to decrypt and receive the message.

Also, a first user can use his private key to sign a message and thesecond user, with the first user's public key, can receive andauthenticate the transmitted message. Thus, the first user isauthenticated to the second user as the one who sent the transmission;i.e., a “digital signature.”

This latter methodology, however, does nothing to guard against theeventuality that a third party is merely pretending to be the sender(i.e., the first user) when the keys were generated in the first place.Therefore, independent and trusted Certification Authorities (CAs) existwhich issue digital certificates verifying the association of a publickey with a particular user, along with other identifying information.

There are two primary modes for phase 1 of IKE: main mode and aggressivemode. Main mode, generally speaking, is a more involved but more securemethod. Aggressive mode, though faster, sacrifices identity protection;however, using the public key encryption methodology just discussedobviates the need for this feature.

In a second phase, IKE negotiates the actual IPsec SA (over which theactual application layer data exchanges will take place) by setting upthe encryption/authentication keys for the AH and/or ESP protocols. Inparticular, “quick mode” negotiates the SAs for general purpose IPseccommunications. Also, it should be noted that, typically, only one phase1 negotiation is needed for an associated plurality of phase 2operations by a plurality of peer devices. This allows the multiple peerdevices to each take advantage of the phase 1 proceedings, therebyestablishing secure connections more quickly and more easily.

As shown in the above discussion, therefore, various solutions exist forimplementing private and authenticated network communications.

However, the various conventional solutions suffer from a variety ofshortcomings. For example, it is often the case that one deviceparticipating in a secure network connection such as IPsec is locatedbehind a gateway or firewall device. As is known, such devices aretypically located on the edge of a private network, and serve tointercept and/or route traffic between the private network devices andother devices, frequently via a public network such as the Internet.Firewalls may be implemented by, for example, corporate networkadministrators and Internet Service Providers (ISPs).

Such firewall devices conventionally serve a number of functions; forexample, they are often used to scan or filter network traffic so as toprevent unauthorized data or data types from entering the privatenetworks. In this way, firewalls may prevent viewing of sites prohibitedby network administrators, such as gambling sites on the Internet. Theymay also prohibit data that is deemed likely to contain viruses or otherfiles that could prove harmful to the network. Firewalls may also beused as the sole entry point to the private network from outside of theprivate network, so that network administrators may require ausername/password combination at the firewall in order to allow onlyauthorized users access.

Conventional firewalls, however, are not designed to operate well inconjunction with security protocols discussed above, such as IPsec. Forexample, if a device on a public network wishes to communicate securelywith a device operating behind a firewall on a private network, nosatisfactory solution exists.

One conventional solution in this scenario is to simply let encrypteddata pass unhindered through the firewall. This solution is shown inFIG. 1A, where devices 100 and 140 (operating on public and privatenetworks 120 and 130, respectively) communicate via firewall 110.However, this solution suffers from the obvious problem that it does notallow the firewall to perform its function of scanning/filtering thedata, and may therefore let harmful or undesirable traffic onto theprivate network.

Another solution would be to establish a secure channel between theremote device and the firewall. Then, decryption can occur at or beforethe firewall, after which the decrypted packets can be scanned/filteredand forwarded to the recipient device within the private network.However, this solution suffers from the fact that operators of thefirewall will have access to the decrypted information intended for therecipient device. In other words, typically a firewall device is not acustomer device; it is a service provider device, and, as such, it isnot typically secure or desirable (from the customer's viewpoint) toallow access to decrypted packets there. Moreover, if it is necessary toestablish a second secure connection between the firewall and the deviceon the private network in order to re-encrypt the data packets (e.g.,negotiate a second SA and set up a second IPsec session), thennon-negligible computing resources must be devoted to this task.

Therefore, what is needed is a system and method for establishing asecure connection between a private network device and a second device,even over a WAN such as the Internet, without permitting a firewalloperator to access a content of data transmitted via the connection.

SUMMARY OF THE INVENTION

In a first exemplary embodiment, the present invention relates to amethod for implementing secure network communications between a firstdevice and a second device, at least one of the devices communicatingwith the other device via a separate computer. Such a method maycomprise obtaining an encryption parameter that is shared by the firstdevice, second device and separate computer and copying a data packetsent by the first device, within the separate computer. Thereafter, themethod may comprise decrypting the copy of the data packet within aportion of the separate computer, wherein contents of the portion areinaccessible to an operator of the separate computer. Finally, themethod may comprise scanning the decrypted copy of the data packet forcompliance with a predetermined criterion associated with the separatecomputer for allowing transmissions therethrough.

In a second exemplary embodiment, the present invention relates to afirewall device for mediating communications between a private networkdevice and a device external to the private network. Such a firewalldevice may comprise an encryption parameter determining circuit operableto determine an encryption parameter that is known to the externaldevice and the private network device, as well as a content scannercontaining the encryption parameter and operable to decrypt contents ofa transmission from the external device for scanning, said contentsbeing encrypted with said encryption parameter, said decrypted contentsbeing inaccessible to an operator of the firewall device. In thefirewall device, the content scanner may permit a forwarding of thetransmission to the private network device upon a determination that thecontents of the transmission comply with a predetermined criterion ofthe firewall device.

In a third exemplary embodiment, the present invention relates to anarticle of manufacture, which comprises a computer readable mediumhaving stored therein a computer program carrying out a method forscanning contents of an encrypted data packet. Such a computer programmay comprise a first code segment for acquiring an encryption parameterused by a first and second device to encrypt a data packet that istransmitted therebetween via the article of manufacture, as well as asecond code segment for decrypting the data packet, using the encryptionparameter. The computer program may further comprise a third codesegment for restricting a user of the article of manufacture fromaccessing contents of the data packet. Finally, the computer program maycomprise a fourth code segment for filtering the data packet based onwhether the contents comply with a predetermined criterion associatedwith the article of manufacture.

In a fourth exemplary embodiment, the present invention relates to amethod of transmitting data. Such a method may comprise constructing afirst encryption parameter with a firewall device that receives andforwards traffic intended for a private network device associatedtherewith, and thereafter constructing with the firewall device, basedon the first encryption parameter, a second encryption parameter thatwas previously negotiated between the firewall device and the privatenetwork device. The method may further comprise receiving at thefirewall device a transmission that is encrypted using the secondencryption parameter, and thereafter sending the received transmissionfrom the firewall device to the private network device.

In a fifth exemplary embodiment, the present invention relates to amethod of transmitting data. Such a method may comprise constructing anencryption parameter with a recipient device through a firewall deviceand sharing the encryption parameter with the firewall device. Themethod may further comprise encrypting a transmission using theencryption parameter. Finally, the method may comprise sending thetransmission to the recipient device via the firewall device.

In a sixth exemplary embodiment, the present invention relates to amethod of filtering encrypted data at a firewall device. Such a methodmay comprise partitioning a filtering portion of the firewall devicefrom an operator thereof, decrypting the encrypted data within thefiltering portion and forwarding the data if it complies with at leastone filtering rule associated with the firewall device.

In a seventh exemplary embodiment, the present invention relates to afirewall device. Such a firewall device may comprise means for obtainingan encryption parameter common to both a first device and a seconddevice, means for decrypting encrypted data transmitted from the firstdevice using the encryption parameter and means for forwarding theencrypted data to the second device.

The features and advantages of the invention will become apparent fromthe following drawings and description.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is described with reference to the accompanyingdrawings. In the drawings, like reference numbers indicate identical orfunctionally similar elements. Additionally, the left-most digit(s) of areference number identifies the drawing in which the reference numberfirst appears.

FIG. 1A demonstrates a prior art networking environment.

FIG. 1B demonstrates a network environment in which one embodiment ofthe present invention might operate, including a firewall operating onthe edge of a private network and communicating with another device viaa public WAN.

FIG. 2 demonstrates a methodology for negotiating a pair of SAsaccording to the embodiment of the invention shown in FIG. 1B.

FIG. 3 describes an embodiment of the invention in which various typesof IPsec traffic is relayed through a firewall computer both waysbetween a pair of devices.

FIGS. 4A, 4B and 4D describe structures of exemplary IPsec packets thatmay be transported according to various embodiments of the invention.

FIG. 4C describes an exemplary IPsec packet that does not requirespecialized scanning related to the present invention.

FIG. 5 demonstrates exemplary hardware components of a firewall computeraccording to one embodiment of the invention.

FIGS. 6A-6D describe exemplary certificate structures for each devicetype when certificates are used within the SA process.

FIG. 7 demonstrates a methodology for negotiating a pair of SAsaccording to an alternate embodiment of the invention.

DETAILED DESCRIPTION

While the present invention is described below with respect to variousexemplary embodiments, the present invention is not limited to onlythose embodiments that are disclosed. Other embodiments can beimplemented by those skilled in the art without departing from thespirit and scope of the present invention.

In this regard, although IPsec is used herein to demonstrate anexemplary embodiment of the invention, it should be understood that thepresent invention can be utilized in the context of other conventionalnetwork security protocols, such as Layer 2 Tunneling Protocol (L2TP)and Point-to-point Tunneling Protocol (PPTP), as would be apparent.Similarly, other protocols/methodologies besides IKE and public keyencryption exist which are useful in implementing network securityprotocols, and the present invention can be implemented in thoseenvironments as well.

Moreover, it should be noted that the terminology and associateddefinitions used herein are subject to some level of disagreement in theart, as is known. For example, some artisans will describe IKE as aninstance of ISAKMP, whereas others will describe IKE as the combinationof ISAKMP with certain other protocols. Such terminology and definitionsare used singularly and consistently herein only for the purposes ofclarity; therefore, it should be understood that such usage is designedmerely to explain and not limit the present invention. Similarly, termssuch as “encryption,” “encryption parameters” or any other term of art,unless otherwise specified or limited herein, are not intended to bere-defined to have a special meaning herein and should be given theirbroadest reasonable interpretations consistent with the conventionalunderstanding in the art.

The present invention, in an exemplary embodiment, operates by modifyingthe functionality of a conventional firewall device operating on theedge of a private network and communicating with another device via apublic WAN, such as the Internet. This configuration is shown in both ofFIGS. 1A and 1B, where device 140 operates on a private network 130behind firewall or other dedicated network appliance 110, andcommunicates via WAN 120 (such as the Internet) with device 100. Notethat device 100 could be a single device on WAN 120, or could beoperating on its own private network or according to any otherconventional network configuration, as would be apparent.

Modifications of such a firewall 110 according to one embodiment of theinvention are implemented in the establishment of a securityassociation(s) (SA(s)) for an IPsec session(s) involving devices 100 and140, as well as in a forwarding mechanism for the packets beingexchanged according to these established parameters.

According to one embodiment of the invention, firewall 110 acquiresinformation such as an encryption parameter(s) that allows it to decrypt(and thereafter scan) incoming data. However, this information isrestricted to a pre-determined portion of the firewall, such as a singlehardware chipset, from which it may not be extracted by an operator ofthe firewall.

In this way, a copy of an incoming data packet can be made and forwardedto the pre-determined portion such as the single chipset; there it canbe decrypted and scanned for compliance with firewall rules. Afterwards,only an affirmative/negative response need be provided by the chipset,whereupon the original version of the data packet (which may be bufferedupon its entry to the firewall 110) can be passed on by the firewall 110to recipient device 140. The copy of the data packet may then simply bedeleted from the chipset where it was decrypted.

In one embodiment of the invention, as discussed with respect to FIGS.1B and 2, two separate SAs and associated IPsec sessions can benegotiated, with firewall 110 forwarding parameters between devices 100and 140. In this embodiment, the three devices collaborate to build acommon secret key.

In another embodiment of the invention, as discussed with respect toFIG. 7, a first SA may be established between devices 100 and 140, and asecond SA may be established between devices 110 and 140. Here, devices100 and 140 first establish a secret key together via the first SA.Device 140 then uses a public key of firewall 110 to pass encrypt andpass the secret key to firewall 110, to be used as described aboveduring IPsec transmissions.

In either embodiment, it will be assumed for the purposes of explanationthat an IP address of device 140 will generally be available to device100 over the public network 120. However, if this is not the case due tothe presence of device 140 on private network 130 that restricts accessto its member device addresses, then it may be necessary to implementsome additional measure(s) for allowing devices 100 and 140 tocommunicate securely. One such exemplary methodology is described indetail in co-pending Application No. (insert number here), which ishereby incorporated herein by reference.

In FIG. 1B, as just described, a device 100 is shown as negotiating SA1with firewall 110. Firewall 110 negotiates a second SA, SA2, with device140. Thereafter, separate IPsec tunnels 1 and 2 are implemented whichallow devices 100 and 140 to securely communicate with one another.During the negotiation of SA1 and SA2, firewall 110 gains access to anencryption parameter that allows it to decrypt information sent betweendevices 100 and 140. However, decryption of the information occurs onlywithin a portion of firewall 110 that is off-limits to an operator ofthe firewall 110. This portion may thus acquire a copy of incoming datapackets, decrypt the copy, scan the copy for compliance with firewallrules, and allow/deny entry of the encrypted packet through the firewall110 and onto private network 130.

FIG. 2 demonstrates a methodology for negotiating a pair of SAsaccording to the embodiment of the invention shown in FIG. 1B. In FIG.2, device 100 seeks to initiate an SA with device 140. Note that device100 may itself be a gateway or firewall device, or it may be a router orsimply a host connected to WAN 120.

As discussed above, an SA describes operations that should be applied tofuture data packets including an authentication method, an encryptionmethod (and associated algorithm), authentication/encryption keys andvarious other parameters (such as the Security Parameter Index (SPI), aneffective lifetime of the key(s), etc.). IKE allows two devices tonegotiate and agree on these operations, including the establishment ofthe keys. As also noted above, it will be assumed for the purposes ofthis description that device 100 has access to a device address ofdevice 140, such as its IP address.

In FIG. 2, device 100 initiates a phase 1 session (PH1) for the first ofthe two conventional phases in negotiating an SA using IKE. In thisembodiment, device 100 sends a message 210 to firewall 110 at an IPaddress F1 of the firewall that may be advertised (i.e., made public)over WAN 120. This message, as discussed above, is generally intended toprotect further negotiation traffic by way of, for example, the Mainmode. As is known, the Main mode provides protection for the identity ofthe involved devices. It is typically divided into three sets ofmessages, each set containing two messages. The first two messages areused for negotiating a security policy for the exchange, the next twomessages are used for the Diffie-Hellman keying material exchange andthe last two messages are used for authenticating the peers, such aswith digital signatures and optional digital certificates.

In one embodiment of the invention, device 100 may be preset such thatit believes that address F1 is an address for device 140. In thisscenario, firewall 110 may be aware upon reception of transmission 210which device with which it will then establish a secondary SA, SA2,without having to inspect the details of the SA transmission 210. Thisimplementation may utilize “loop-back” addresses on firewall 110, onefor each possible peer on private network 130. In other words, therewill be a different address F1 associated with each of the privatenetwork devices.

Another implementation utilizes a single F1 IP address for all IPsecflows on the WAN side. In this solution, firewall 110 must examine thetransmission 210 to determine which private network device will be thetunnel endpoint for communications with device 100. This implementationhas the advantage that a device 100 can communicate with a plurality ofdevices on private network 130, while itself needing to establish anSA(s) only with firewall 110 (i.e., one SA per destination device).

In the latter implementation there is a need to maintain a name andidentity of device 100, either locally at the firewall 110 or at aDomain Name System/Server (DNS). This information can also be used toidentify device 140 as the sought-after device.

It should be noticed that SA2 may start by using a similar message 220upon reception by firewall 110 of the first SA1 message. In the variousscenarios discussed above, in cases where firewall 110 does not know theidentity of the destination device 140 by one of the above-definedmethods, it will wait for an SA message from device 100 containing anidentification payload. In such a case, firewall 110 should proceed witha phase 1 negotiation with device 100 until this message is received.

FIG. 2 describes only the case when either the identity of device 140 isincluded in the first message 210 or is already known by firewall 110.One limitation when the destination identity is not known is thatfirewall 110 should not start negotiating parameters which may turn outto be unsuitable for device 140; a solution in this case is to define acommon set of rules which will be accepted by all devices on privatenetwork 130.

Assuming firewall 110 is aware of the identity of device 140, firewall110 may then start a secondary phase 1 SA message 220 for SA2, usinganother IP address F2 for firewall 110 that belongs to private network130 and to which device 140 will be able to answer. Device 140 is nowthe SA responder and will answer to firewall 110 using a PH1 BA typemessage 230. In other words, device 140 will receive parametersassociated with device 100 but having address F2, and will respond withits own parameters to that address.

Afterwards, firewall 110 responds to the first SA message 210 andprovides a similar answer PH1FA message 240 to device 100. In otherwords, the same parameters are negotiated between firewall 110 anddevice 100 as between firewall 110 and device 140. The two SAs are thusindependent, but will negotiate the same rules and parameters thanks tothe interleaving of the SA messages.

At this point firewall 110 provides its own authentication parameters,such as its own authentication public key, but uses the identity ofdevice 140. If this checking is done via certificates, then thecertificates will be defined according to FIG. 6, as will be discussed.

It should be noted that the SA mechanisms between device 100 andfirewall 110 on one side and device 140 and firewall 110 on the otherside fully meet the IKE protocol rules and process, so that no change isrequired on devices 100 or 140, which are therefore transparent to thisimplementation.

Once phase 1 is achieved, a fully secure authenticated channel withpossible encryption is established in order to proceed with SA phase 2.Phase 2 allows the definition of parameters for the IPSec protocolitself, and generally makes use of the Quick mode discussed above. ADiffie-Hellman key exchange may be done to achieve forwarding secrecy.

As referred to above, the conventional Diffie-Hellman methodology allowstwo users to build a symmetric secret key (same key used for encryptionand decryption) using their local private keys, a known Diffie-Hellman(DH) key and the other device's public key (which can either betransmitted via firewall 110, or is obtained from a certificate).

Although conventionally implemented for two users as just explained,this methodology can be extended for any number of users. According tothis embodiment of the present invention, a secret shared key can bedeveloped using the Diffie-Hellman algorithm that is common to all ofdevices 100, 110 and 140.

For example, at the beginning of a use of the Diffie-Hellman algorithm,device 100 having address A generates a private key referred to as “a.”A corresponding public key will have the form T_(a)=g^(a), where theparameter “g” is a known parameter according to the Diffie-Hellmanalgorithm, i.e., the DH key. Similarly, firewall 110 will have privatekey “f” and public key T_(f)=g^(f), while device 140 will have privatekey “b” and public key T_(b)=g^(b).

Thereafter, device 100 may send public key T_(a) to firewall 110, whichcan then calculate a secret key S_(af)=(T_(a))^(f)=g^(af). Firewallsimilarly sends T₁ to device 100, which can then calculate the secretkey S_(fa)=(T_(f))^(a)=g^(af)=S_(af). Thus, devices 100 and 110 share acommon secret key, hereafter referred to as “C.”

Once devices 100 and 110 share key C, they may each calculate the samepublic key T_(C)=g^(C). Device 140 having private key “b,” meanwhile,calculates public key T_(b) g^(b), as already pointed out.

Thereafter, device 140 sends T^(b) to firewall 110, which can calculatesecret key S_(bC)=(T_(b))^(C)=g^(bC). Firewall similarly sends T_(C) todevice 140, which can then calculate secret keyS_(Cb)=(T_(C))^(b)=g^(Cb)=S_(bC).

Finally, to upgrade the secret shared key C with device 100, thefirewall 110 forwards T_(b) to device 100, and then device 100 cancompute the new secret key in the same manner as just performed byfirewall 110, using secret key C which it already posses from before,i.e.: S_(bC)=(T_(b))^(C)=g^(BC).

In short, devices 100 and 110 calculate a secret key sharedtherebetween. Thereafter, devices 110 and 140 calculate a second secretkey shared therebetween, using the first secret key. Finally, device 100is able to calculate the second secret key using the first secret keyand the public key of device 140. Thus, all three devices share the(second) secret key in common, which can be used forencrypting/decrypting IPsec packets.

Another way of describing the same method is to say that device 100calculates the secret key using its common secret key (C) establishedwith device 110, the DH key and the public keys of device 140, whiledevice 140 calculates the same secret key using its own local privatekey, the DH key and the common public key (T_(c)) of devices 100 and110. The common secret key (S_(bC)), once calculated by firewall 110,should only be stored within, for example, a hardware chipset that isnot accessible by an administrator of the firewall.

Note that in this description, the secret key is calculated twicebetween devices 100 and 110. However, device 140 may also initiate theexchange(s). In either case, only one of the two end devices should haveto perform the two-step secret key calculation.

As long as the SAs between device 100 and firewall 110, and betweenfirewall 110 and device 140, are valid, the same secret key is valid.Therefore the same parameters of key lifetime should typically benegotiated both ways.

Either one of the devices 100 or 140 might initiate the quick modeexchange associated with phase 2 SA negotiations. In FIG. 2, device 140is the initiator of the second phase starting with PH2BI message 250.Firewall 110 rebuilds a similar message PH2FI 260, where theauthentication (public) key of device 140 is replaced with a computationof the public keys of devices 110 and 140 together (since device 100will need the parameter of device 140 for the secret key computation, asjust described).

Device 100 answers with its own parameters in PH2AA message 270 tofirewall 110, and the firewall 110 forwards the message including thesame parameter values, except for the authentication key of device 100,which is exchanged for a combination of itself and the key of firewall110, to device 140 in PH2FA message 280.

Note that an additional message may be sent by Firewall 110 to providedevice 100 with the IP address to use during the IPsec session as theaddress for device 140, especially when the SA IP address for device 140is not the same as the one used for IPsec traffic.

A last message that can be viewed as a final acknowledge is also sentback which is not shown in FIG. 2. Such a message ends the SA(s) forIPsec traffic between devices 100 and 140. As SAs are typicallyasymmetrical, it may be necessary to repeat the above-described processin the reverse direction. However, it may be necessary only to perform aphase 2 negotiation, as is known. Once all SAs are active, the IPsectraffic can start in both directions.

FIG. 3 describes IPsec traffic both ways between devices 100 and 140through firewall 110. In FIG. 3, only an ESP header is used (i.e., asexplained above, encryption is involved but no full packetauthentication is necessarily provided). AH may be used in conjunctionwith ESP if full packet authentication is required, as is known;however, this scenario is not explicitly shown in FIG. 3. In the casewhere AH is used alone without encryption (i.e., with a packet using theformat described in FIG. 4C, below), the firewall 110 can simply performconventional filtering (since the present invention will not be neededin that scenario).

In FIG. 3, a first IPsec packet is sent from device 100 to firewall 110in step 310. When firewall 110 recognizes a packet having F1 asdestination address, it first checks a protocol field (“PROT”) field inthe packet in order to know which process to use. The PROT will indicatewhether to use an IPSec ESP flow process or an IPSec AH (+ESP or not)flow. In step 310, the protocol is ESP, and therefore firewall 110 hasto copy the packet, store (buffer) the original, decrypt the copiedpayload and scan the copied payload content. If the copied packet isvalid, the original is then forwarded to device 140; otherwise, thepacket is discarded and a message can be logged to that effect fornetwork management purposes. Note that the original, buffered packet isforwarded to device 140; in this way, no re-encryption is performed infirewall 110, and the packet can be easily and quickly forwarded uponapproval of the copied and scanned version of the packet.

FIGS. 4A, 4B and 4D describe structures of exemplary IPsec packets thatmay be transported according to various embodiments of the invention.FIG. 4C describes an exemplary IPsec packet that does not requirespecialized scanning related to the present invention.

In FIG. 4A, packet 410 represents an IPsec packet using IPsec tunnelmode with an ESP header 416. The inner payload 412 and IP header 414 areencrypted, while the entire packet except the tunnel header 418 isauthenticated (i.e. integrated in the packet signature).

In FIG. 4B, packet 420 represents an IPsec packet using IPsec transportmode with ESP header 428 and Generic Routing Encapsulation (GRE)tunneling. The inner payload 422 and IP header 424 as well as the GREportion 426 are encrypted, while the entire packet except the tunnelheader 429 is integrated in the packet signature (i.e., authenticated).

In FIG. 4C, packet 430 represents an IPsec packet using IPsec tunnelmode with AH header 436. No field is encrypted, while the entire packetincluding the tunnel header 438 is integrated in the packet signature.Therefore, no special process according to the present invention is donein firewall 110 with such packets. Rather, they are just monitored by alegacy firewall function capable recognizing the AH header in order toproperly locate the original IP header and payload.

In FIG. 4D, packet 440 represents an IPsec packet using IPsec tunnelmode with AH and ESP headers 448 and 446, respectively. The innerpayload 442 and IP header 444 are encrypted, while the entire packetincluding the tunnel header 449 is integrated in the packet signature.

FIG. 5 demonstrates exemplary hardware components of a firewall computer510 according to one embodiment of the invention.

Firewall 510 includes two interfaces with which to interact with the twoexternal networks 120 and 130. The first interface INTF A 520 has oneinput WAN_IN and one output WAN_OUT. When a packet arrives on WAN_INinterface, it is transmitted to the INPUT process block 530 via P_INleads and data bus. This process determines whether the packet is a datapacket (which may or may not be encrypted), or if it is an SA messagemarked for interception by Firewall 510.

In the latter case, the packet is transmitted via SA_A_IN lead to the SAmanagement and key negotiation block of the WAN side, i.e., SA MGT & KEYNEGO. A 570. At this point, the process described in FIG. 2 isperformed; this process may involve message modification, coding ordecoding and/or an answering transmission(s) to device 100 via an SA_AOUT lead. Similarly, when an SA message is received from device 140 onINTF B 560, it is received on SA MGT & KEY NEGO. B 580 via SA B IN.Answers to an SA message from device 140 are sent using an SA B OUT leadto OUTPUT process 550, which serves to queue all packet flows.

Information is sent from one SA management block (570, 580) to the otherby way of SA BRIDGE 595. SA bridge may serve to perform theDiffie-Hellman 3^(rd) party computation and key creation describedabove, using Firewall 510 public key T_(f) given to devices 100 and 140.In addition, the encryption public key from device 100, T_(a), is sentby block 570 to block 590 and similarly the encryption Public Key from Bis sent by block 580 to block 590. In this way, Secure Content FirewallScanner 590 is able to compute the secret shared key using theencryption public keys T_(a) and T_(b) together with its own encryptionprivate key “f.” Therefore, the secret key always remains secure in chip590, and is never visible to users or administrators of the firewall,nor may it be found using hardware analyzers.

When the packet is a conventional, unencrypted IP packet (or a packetusing only an IPsec AH header, as shown in FIG. 4C), rather than an SAmessage, the packet is forwarded by INPUT process 530 to standardfirewall function STDF 545, which performs all necessary filteringand/or data scanning, as necessary. Then, if not filtered out, thepacket is forwarded to OUTPUT process 550 for queuing for export tointerface INTF B 560. The packet will then be transmitted on NET_OUTlink, as shown.

If the packet is neither an SA message or a normal (non-encrypted)packet but an encrypted one defined as “to be scanned,” then it isstored in Packet Buffer 540 using leads and data bus P-STO. A commandSCAN_REQ is also sent by INPUT process 530 to Secure Content FirewallScanner 590. The command SCAN_REQ contains a packet pointer, such as apacket number, that allows Secure Content Firewall Scanner 590 to get acopy of the packet for decryption, via P-RD Bus. Once decrypted, thepacket copy is checked using standard firewall rules. The result may beeither to discard the original packet stored in Packet Buffer 540 orallow its transmission; in either case, Secure Content Firewall Scanner590 may then discard the scanned copy of the packet.

Alternatively, modification of the packet to conform with firewall rules(or extract only those portions that do not conform with firewall rules,and allow the rest to pass) is also feasible, as would be apparent toone of skill in the art. For example, such packet modification might beimplemented by way of a data transmission mechanism from Secure FirewallContent Scanner 590 to block 550.

The SD_AT lead informs OUTPUT Process 550 to send (SD) the packet orAbort (AT) the packet transmission. SD_AT may also include a packetpointer, such as a packet number, in order to identify the packet. Aclear CL_GT command can then be sent by OUTPUT Process 550 to clear orfetch the above-mentioned packet, using the packet pointer. In thelatter case, the packet can be forwarded from PACKET BUFFER 540 toOUTPUT process 550 using P_FW bus. The packet can then be transmitted onthe NET_OUT link via INTF B 560 and the P_OUT bus.

The mechanism just described with respect to FIG. 5 is a one-waymechanism, in that it protects data going from device 100 on WAN 120 todevice 140 on private network 130. However, inasmuch as the process ofencrypted traffic transmission is asymmetrical for the SA, and for theencrypted traffic itself (which may use different set of keys andparameters), another Secure Firewall Content Scanner chip (or the sameif shared), as well as another set of INPUT and OUTPUT processes blocksand Packet Buffer, may be implemented to scan encrypted data transmittedfrom the direction of device 140 to device 100.

FIG. 6 describes exemplary certificate structures for each device typewhen certificates are used within the SA process. The certificates 600 aand 600 b for devices 100 and 140 in FIGS. 6A and 6B can be standard or“true” certificates, as all the parameters included in the certificatefields really belong to those devices. A certificate 600 a for deviceaddress A as in FIG. 6A is only given to a device located on WAN 120,and a certificate 600 b for device address B as in FIG. 6B is only givento a device located on private network 130.

As shown in FIG. 6A, a portion 610 a of certificate 600 a may containthe certification authority (CA) identity and signature, while a portion620 a contains various information for device 100 having address A,including its identity on the WAN 120, IP address, device public key,IPsec authentication public key and IPsec encryption public key.

Similarly, as shown in FIG. 6B, a portion 610 b of certificate 600 b maycontain the CA identity and signature, while a portion 620 b containsvarious information for device 140 having address B, including itsidentity on the private network 130, IP address, device public key,IPsec authentication public key and IPsec encryption public key.

FIG. 6C demonstrates a type of certificate 600 c that a device 140having device address B (or a similarly-situated device) may receivewhen it requests a certificate for a device such as device 100 havingdevice address A (or a similarly-situated device). A certificate such as600 c is a valid “false” certificate, since it is validated by the CAeven though it contains some fields with false information in order towork properly. That is, if certificate 600 c is considered to belong tofirewall 110, then firewall 110 is impersonating device 100 havingaddress A in purporting to possess that device's identity (as far as theprivate network 130 is concerned) and a public encryption key thatincludes that device's public encryption key plus the firewall's ownpublic encryption key.

Similar comments apply in the inverse to certificate 600 d in FIG. 6D.Such a certificate 600 d allows firewall 110 to impersonate device 140having address B, but presenting its own device public key and IPsecencryption public key.

FIG. 7 demonstrates a methodology for negotiating a pair of SAsaccording to an alternate embodiment of the invention.

In FIG. 7, a first SA 710 is established between devices 100 and 140through firewall 110. A second SA 720 is then established betweenfirewall 110 and device 140. Devices 100 and 140 first agree, inexchange 730, on an IPsec encryption secret key Ke. Thereafter, this keyKe is encrypted by device 140 using an encryption public key of firewall110, resulting in PkF(Ke). Then, the encrypted Ke (i.e., PkF(Ke)) isforwarded to firewall 110 by message 740 within SA2 720. Firewall 110decrypts PkF(Ke) to obtain Ke, and thereafter is free to use Ke todecrypt/scan packets in the manner described above with respect to FIG.5. Note that, although FIG. 7 describes the case where SA2 isestablished between devices 110 and 140, it could just as easily beestablished between devices 100 and 110. Also, in this embodiment, itmay be necessary to build and use separate keys for transmissions andreceptions between devices 100 and 140. If an operator decides to usethis feature, then either device 100 can be used to provide both keys,or the process can be run such that device 140 provides the second key.

In conclusion, the present invention has described a methodology forscanning incoming data without sacrificing the security of the data. Indoing so according to one embodiment of the invention, a common secretkey is shared between two endpoint devices and a firewall device. Datais received, buffered and copied upon its entry to the firewall; thecopy of the data is decrypted and scanned, using the common secret key,in a portion of the firewall that is inaccessible to an operator of thefirewall. If the data does not violate any firewall rules, then theoriginal, buffered data may be passed through the firewall while thescanned copy is deleted. Otherwise, both copies may be deleted, and anetwork administrator and/or the message sender may be notified that afirewall rules violation has occurred.

Although various embodiments of the present invention have beendescribed in detail herein, not all features and/or implementations ofthe invention have been described. For example, although WAN 120 hasprimarily been discussed as a public network such as the Internet, itmay be a local area network (LAN), a private network, etc. Also, onlytwo end peers are discussed in detail in this description, as IPsec is apoint-to-point protocol. However, more devices may be interconnectedbetween them through a firewall. It is also possible that more than onedevice on one side will establish a secure communication to the samedevice on the other side, even though each IPsec communication isseparate and requires it own corresponding security association.

Thus, it should be apparent that while this invention has been describedin various explanatory embodiments, other embodiments and variations canbe effected by a person of ordinary skill in the art without departingfrom the scope of the invention.

1. A method, comprising: based on a first negotiation pursuant to afirst agreement setting conditions for packet-based networkcommunications, negotiating a second agreement setting conditions forpacket-based network communications; accessing an encryption parameterconfigured to decrypt information sent between two devices that areparties to the first and second negotiations; and implementing securecommunications between the two devices based on the first and secondnegotiations and the encryption parameter.
 2. The method of claim 1,wherein the negotiating the second agreement includes negotiating atleast one of an authentication method, an encryption method or anauthentication or encryption key.
 3. The method of claim 1, wherein theimplementing secure communications between the two devices includesestablishing the first agreement between a first of the two devices andan intermediary device.
 4. The method of claim 3, wherein theimplementing secure communication between the two devices includesestablishing the second agreement between the intermediary device and asecond of the two devices.
 5. The method of claim 3, wherein theestablishing the first agreement between the first of the two devicesand the intermediary device includes examining, by the intermediarydevice, a transmission from the first of the two devices to determine anidentity of the second of the two devices.
 6. The method of claim 4,wherein the establishing the second agreement between the intermediarydevice and the second of the two devices includes representing theintermediary device to the second of the two devices in terms of anaddress associated with a private network.
 7. The method of claim 6,wherein the implementing the secure communications between the twodevices includes decrypting, by the intermediary device, incoming datawherein operations associated with the decrypting are performed in aportion of the intermediary device to which access is restricted.
 8. Acommunication device, comprising: a first interface configured tocommunicate with a first network; a second interface configured tocommunicate with a second network; first negotiation logic configured tonegotiate a first agreement that controls communication associated withthe first network; second negotiation logic configured to negotiate asecond agreement that controls communication associated with the secondnetwork; and security logic coupled to the first negotiation logic andthe second negotiation logic, wherein the security logic is configuredto compute and store a key configured to decrypt packets exchangedbetween a first device on the first network and a second device on thesecond network according to the first agreement and the secondagreement.
 9. The communication device of claim 8, further comprisingbridge logic configured to bridge the first negotiation logic and thesecond negotiation logic and that is coupled to the security logic,wherein the bridge logic is configured to perform Diffie-Hellmancomputation and key creation based on a public key received from thesecurity logic.
 10. The communication device of claim 8, furthercomprising a packet buffer configured to store an encrypted data packet.11. The communication device of claim 10, wherein the security logic isconfigured to obtain a copy of the encrypted data packet from the packetbuffer and decrypt the copy of the encrypted data packet using the key.12. The communication device of claim 13, wherein the security logic isconfigured to check the decrypted copy for compliance with one or moredata security rules.
 13. The communication device of claim 12, whereinbased on the checking, the security logic is configured to one of:discard the encrypted data packet in the packet buffer; or allowtransmission of the encrypted data packet in the packet buffer.
 14. Thecommunication device of claim 8, wherein the security logic isconfigured to store the key in a portion of the security logic to whichaccess is restricted.
 15. The communication device of claim 8, whereinthe first network includes a public network and the second networkincludes a private network.
 16. An apparatus, comprising: firstinterface means for receiving data packets from a first network; secondinterface means for receiving data packets from a second network; andsecure content checking means for checking encrypted data packets fromthe first network or the second network for compliance with a datasecurity standard, at least in part using an encryption parameter storedin hardware means to which access is restricted.
 17. The apparatus ofclaim 16, wherein the secure content checking means comprises encryptionparameter computation means for computing the encryption parameter. 18.The apparatus of claim 16, further comprising means for modifying a datapacket to comply with the data security standard.
 19. The apparatus ofclaim 16, further comprising means for performing Diffie-Hellmancomputation.
 20. The apparatus of claim 16, further comprising means forbuffering an encrypted data packet.
 21. A computer-readable storagemedium having computer-executable instructions that, in response toexecution, cause a computing system to perform operations, comprising:receiving, by a computing system, data packets from a first network;receiving, by the computing system, data packets from a second network;and checking encrypted data packets from the first network or the secondnetwork for compliance with a data security standard at least in part asa function of an encryption parameter stored in hardware for whichauthentication is made unavailable to an administrator or operator ofthe computing system.